REPORT  DOCUMENTATION  PAGE 


Form  Approved 
0MB  No,  0704-0188 


Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources, 
gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this 
collection  of  information,  including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Report^  121 5  Jefferson 
Davis  Highway,  Suite  1 204,  Arlington,  VA  22202-4302,  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704.-0188),  Washington,  DC  20503. 


1.  AGENCY  USE  ONLY  riea»/'e  WanW 


2.  REPORT  DATE 

I  12.Jul.?? _ 


4.  TITLE  AND  SUBTITLE 

GROUND  BASED  INTERCEPT  OF  A  BALLISTIC  MISSILE:  SIMULATION 
TRUTH/MODEL  INTERFACE 


6.  AUTHOR(S) 

2D  LT  CONE  KYLE  M 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

UNIVERSITY  OF  COLORADO  AT  COLORADO  SPRINGS 


3.  REPORT  TYPE  AND  DATES  COVERED 

THESIS 


5.  FUNDING  NUMBERS 


8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 


9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

THE  DEPARTMENT  OF  THE  AIR  FORCE 
AFIT/CIA,  BLDG  125 
2950  P  STREET 
WPAFB  OH  45433 


10.  SPONSORING/MONITORING 
AGENCY  REPORT  NUMBER 

FY99-168 


12a.  DISTRIBUTION  AVAILABILITY  STATEMENT 

Unlimited  distribution 

In  Accordance  With  AFI  35-205/ AFIT  Sup  1 


12b.  DISTRIBUTION  CODE 


13.  ABSTRACT  (Maximum  200  words) 

DISTRIBUTION  STATEMENT  A 

Approved  for  Public  Release 

Distribution  Unlimited 

14.  SUBJECT  TERMS 

15.  NUMBER  OF  PAGES 

22 

16.  PRICE  CODE 

17.  SECURITY  CLASSIFICATION 
OF  REPORT 


18.  SECURITY  CLASSIFICATION 
OF  THIS  PAGE 


OF  ABSTRACT 


ABSTRACT 


Standard  Form  298  (Rev.  2-89)  (EG) 

Prescribed  by  ANSI  Std,  239.18 

Designed  using  Perform  Pro,  WHS/DIOR,  Oct  94 


GROUND  BASED  INTERCEPT  OF  A  BALLISTIC  MISSILE: 
SIMULATION  TRUTH/MODEL  INTERFACE 

by 

KYLE  MATTHEW  CONE,  2LT,  USAF 
B.S.,  Purdue  University,  1998 

A  Creative  Investigation  submitted  to  the  Graduate  Faculty  of 
the  University  of  Colorado  at  Colorado  Springs 
in  partial  fulfillment  of  the 
requirements  for  the  degree  of 
Master  of  Engineering  in  Space  Operations 
Department  of  Mechanical  and  Aerospace  Engineering 

1999 


©  Copyright  By  Kyle  Matthew  Cone  1999 
All  Rights  Reserved 


iii 


Cone,  Kyle  Matthew  (M.E.,  Engineering  Space  Operations) 

Ground  Based  Intercept  of  a  Ballistic  Missile: 

Simulation  Truth/Model  Interface 

Creative  Investigation  directed  by  Doctor  Don  Caughlin 

This  investigation  encompassed  a  study  of  the  integration 
and  operation  of  the  Satellite  Tool  Kit  and  Missile  Flight  Tool 
modules.  The  Satellite  Tool  Kit  display  and  Missile  Flight  Tool 
truth  data  designed  in  this  investigation  are  components  of  a 
ballistic  missile  defense  simulation,  and  are  required  to 
visualize  and  begin  the  simulation.  Further,  the  integration 
and  visualization  of  several  of  the  ballistic  missile  intercept 
system  components  was  explored. 
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Introduction 


The  Ground  Based  Intercept  (GBI)  simulation  was  a  team- 
effort  simulation  that  asked  its  simulators  to  address  the 
technical  issues  associated  with  the  detection,  acquisition  and 
hit  of  an  incoming  ballistic  missile.  As  the  simulation 
truth/model  interface  architect,  I  was  charged  with  generating 
truth  data  for  an  intercontinental  ballistic  missile  in  flight. 
Further,  I  was  responsible  for  presenting  the  Ground  Based 
Interceptor  simulation  in  a  visual  format.  I  used  the  Satellite 
Tool  Kit  software  to  present  the  results  of  the  simulation  in  a 
detailed,  graphical  format,  and  I  used  the  supplementary  Missile 
Flight  Tool  module  to  model  an  intercontinental  ballistic 
missile  and  generate  its  corresponding  truth  data.  Each  GBI 
team  member  was  given  a  specific  role  and  a  specific  area  of 
interest  to  examine.  The  respective  roles  and  areas  of  interest 
of  the  team  are  defined  below: 

1 .  Program  Manager 

2 .  System  Engineer 

3 .  Simulation  Truth/Model  Interface  Architect 

4.  Control  Engineer  (vehicle  control) 

5.  Radar  Engineer  (Tracking,  Discrimination) 
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6.  IR  Engineer  (Detection,  Tracking) 

7.  Battle  Manager  (Sensor  Fusion) 

8 .  GPS  Engineer 

This  paper  details  the  Simulation  Truth/Model  Interface 
portion  of  the  GBI  simulation  project. 

Background 

The  Simulation  Truth/Model  Interface  architect  was  charged 
with  providing  the  different  simulation  components  with  threat 
data  and  a  visual  forum  to  display  and  view  their  roles  in  the 
simulation.  These  different  simulation  components  include 
infrared  satellites  and  sensors,  the  battle  manager  facility, 
the  search  and  track  radars,  the  GPS  satellites  and  the  Exo- 
atmospheric  Kill  Vehicle  (EKV) .  A  visual  forum  was  provided  by 
the  Satellite  Tool  Kit  (STK)  satellite  systems  analysis  software 
and  the  supplementary  Missile  Flight  Tool  (MFT)  module  provided 
by  Analytical  Graphics,  Inc  (AGI) . 

Providing  threat  data  consisted  of  providing  the  position 
and  velocity  data  of  the  enemy  Intercontinental  Ballistic 
Missile  (ICBM)  to  the  IR  satellites  and  the  search  and  track 
radars  in  the  simulation.  Passing  this  data  to  each  was 
accomplished  by  modeling  the  flight  of  the  ICBM  in  MFT,  passing 
that  data  to  STK,  saving  the  data  as  a  text  file,  modifying  it 
to  a  MATLAB  m-file  and,  finally,  passing  it  into  a  MATLAB 
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Simulink  model.  In  Simulink,  the  data  was  used  to  continue  the 
simulation. 

Simulation  truth 

In  order  to  begin  the  simulation,  it  was  necessary  to  have 
true  data  that  accurately  portrayed  the  position  and  velocity  of 
the  incoming  ICBM.  This  data  was  simply  the  ephemeris  from  the 
ICBM  and  its  reentry  vehicles  (RVs)  as  it  traversed  its 
trajectory  as  modeled  in  MFT.  Specifically,  the  truth  data 
included  the  time,  latitude,  longitude,  altitude,  latitude  rate, 
longitude  rate  and  altitude  rate  of  the  ICBM  and  both  the  actual 
and  decoy  RV.  The  entire  Ground  Based  Interceptor  (GBI) 
simulation  relied  on  the  truth  data  for  an  accurate  depiction  of 
the  ICBM's  flight  and  both  RV's  deployment  and  descent. 

A  master  truth  file,  containing  specific  missile-status 
information  could  have  been  created.  This  master  truth  file 
would  have  contained  data  on  each  of  the  ICBM's  components  - 
each  of  the  three  stages,  the  shroud  and  each  of  the  RVs. 
Moreover,  this  master  truth  file  would  have  data  on  each  of  the 
missile's  part's  ascent,  separation  and  descent.  Therefore, 
with  this  master  file,  one  would  have  known  the  entire  history 
of  the  ICBM.  One  would  have  known  where  it  was  at  each  time 
step  and  what  its  status  was,  including  stage  separation,  shroud 
separation  and  RV  status.  Restricting  the  data  to  that  required 
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by  the  simulation  in  two  truth  files,  one  for  the  primary  target 
RV  and  the  other  for  the  decoy  RV. 

Simulation  Environment 

Satellite  Tool  Kit 

In  order  to  see  the  ICBM  launch,  fly  and  separate,  and  in 
order  to  see  the  target  RV  and  the  decoy  RV  deploy,  a  program 
capable  of  presenting  results  in  a  detailed,  graphical  format 
was  necessary.  Furthermore,  this  program  needed  the  ability  to 
propagate  satellites,  model  sensors  in  different  environments 
and  display,  on-screen,  when  a  sensor  could  "see"  the  ICBM.  The 
Satellite  Tool  Kit  software  went  above  and  beyond  the 
aforementioned  criteria;  therefore,  the  STK  software  was  chosen 
to  visualize  the  actions  of  the  different  simulation  components 
during  the  simulation. 

Satellite  Tool  Kit  is  a  commercial-off-the-shelf  satellite 
systems  analysis  tool  used  by  the  space  industry  to  visualize, 
model,  simulate  and  analyze  conplex  scenarios  involving  an 
extensive  range  of  options  above  and  beyond  the  obvious 
satellite.  The  STK  software  allows  a  user  to  not  only  propagate 
a  satellite's  position  in  time,  but  also  determine  the  time  one 
object  can  see  or  "access"  another  object;  this  tool  became 
extremely  useful  in  our  GBI  simulation.  Further,  STK  allows 
modeling  of  other  vehicles  and  objects  such  as  airplanes,  ships. 
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ground  vehicles,  facilities,  planets,  stars,  receivers, 
transmitters  and  sensors . 

STK  provides  a  user  with  many  options,  one  of  which  is  to 
model  different  behaviors.  These  behaviors  include,  but  are  not 
limited  to,  drag  affects  on  an  object,  solar  radiation  affects 
on  a  satellite  and  any  third-body  gravitational  affects.  A  user 
has  the  option  to  define  the  coordinate  system  in  which  to 
orient  the  object  as  well.  Not  only  can  a  user  add  affects  to 
the  scenario,  but  one  can  also  set  constraints  on  objects. 

These  constraints  include,  but  are  not  limited  to,  positions  of 
the  Sun  and  Moon,  time-based  constraints  on  a  facility  or  target 
and  standard  constraints  such  as  minimum  and  maximum  angles  and 
altitudes . 

Missile  Flight  Tool 

In  order  to  launch  and  propagate  the  ICBM  based  on  actual 
flight  profiles,  a  program  that  modeled  "real  world  flight"  of 
an  actual  ICBM  was  critical.  The  ability  to  model  the 
deployment  and  descent  of  reentry  vehicles  was  also  critical  to 
the  task  of  modeling  an  actual  ICBM.  To  have  STK  visualize  the 
launch  and  flight  of  the  ICBM,  a  program  that  was  already  a  part 
of  STK,  or  one  that  could  interface  with  STK  was  necessary,  too. 
The  Missile  Flight  Tool  module  of  Satellite  Tool  Kit  satisfied 
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'^Missile  Flight  Tool  is  a  high-fidelity  missile  flight  path 
generator.,,"^  that  enables  the  user  to  easily  understand  complex 
missile  Operations.  By  integrating  MFT  with  STK,  a  set  of 
unclassified  databases  is  opened  to  the  user.  These  databases 
represent  a  wide  range  of  different  missile  types  and 
performance  capabilities  that  allows  one  the  capacity  to 
generate  multiple-stage  missile  trajectories.  Further,  a  user 
can  easily  analyze  and  visualize  complex  relationships  between 
any  portion  of  the  missile  phase,  operations  and  satellite 
systems  with  the  integration  of  MFT  and  STK. 

MFT  is  an  easy  tool  to  use  for  the  established  and 
e3<perienced  user.  It  is  the  installation  of  and  initial  use  of 
Missile  Flight  Tool  that  can  cause  the  user  a  great  deal  of 
anxiety  and  stress.  Since  MFT  is  an  STK  module,  the  use  of  MFT 
requires  a  password  and  either  a  computer  station  host  ID  number 
or  an  expiration  date.  In  fact.  Missile  Flight  Tool  is  so 
sophisticated  that  it  requires  a  special  export  license 
agreement  with  AGI.  Certain  aspects  of  the  MFT  module  and 
details  of  the  missile  databases  contained  within  the  module  are 
considered  'sensitive  material.'  Therefore,  only  certain 
countries  and  persons  are  cleared  to  use  this  module. 

Unlike  the  Satellite  Tool  Kit  ballistic  missile  propagator, 
which  simply  flies  a  vehicle  on  an  elliptical  path  beginning  and 
ending  at  the  Earth's  surface,  the  Missile  Flight  Tool  missile 
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propagator  models  ICBMs  properly,  meaning,  it  models  the  "real 
world  flight"  of  an  ICBM.  To  illustrate,  the  MFT  module  offers 
staging  phases  and  reentry  vehicle  capabilities  while  the 
standard  STK  ballistic  propagator  version  does  not.  Moreover, 
the  supplementary  module  is  able  to  model  eleven  different 
missiles.  Each  missile  is  defined  by  its  maximum  range,  number 
of  stages,  n\jmber  of  RVs  and  guidance  type.  The  missiles  vary 
between  short  test  missiles  with  a  maximum  range  of  300 
kilometers  and  strategic  ICBM  missiles  with  a  maximum  range  of 
12000  kilometers. 

MFT  provides  a  user  with  many  other  options,  one  of  which 
is  to  model  different  behaviors  and  forces  acting  on  the  missile 
in  question.  These  behaviors  and  forces  include,  but  are  not 
limited  to,  an  oblate  versus  a  spherical  Earth  and  atmospheric 
density,  pressure  and  temperature.  Also,  MFT  uses  a  wide 
variety  of  functions  and  procedures  that  deal  with  the  physical 
shape  and  characteristics  of  the  Earth. 

Process 

Overall  integration  framework 

The  Ground  Based  Interceptor  simulation  began  and  will  end 
using  Satellite  Tool  Kit;  MFT  generated  the  truth  data.  This 
truth  data,  along  with  system  time,  was  then  input  into  Simulink 
to  continue  the  simulation.  In  the  end,  the  different 
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simulation  components  will  output  each  of  their  data  to  text 
files,  which  is  input  into  STK.  The  end  result  will  be  a 
complete,  dynamic  display  of  our  GBI  simulation,  including  a 
comparison  of  the  different  truth  data  versus  actual  data;  the 
incorporation  of  GPS  truth  data  will  be  described  later. 

The  GBI  simulation  began  with  opening  the  MFT  and  STK 
applications.  Initially,  many  others  and  I  thought  that  the 
Missile  Flight  Tool  module  was  already  installed  on  the  Master 
of  Engineering  Program  Office's  computer  stations;  however,  MFT 
is  not  included  on  the  standard  load. 

An  additional  MFT  compact  disc  from  Analytical  Graphics, 
Inc.  is  required.  Simply  following  the  installation  procedures, 
however,  did  not  work.  To  explain,  the  computer  station  did  not 
recognize  the  module!  To  alleviate  this  problem,  the  password 
had  to  be  manually  installed.  To  ensure  this  situation  did  not 
happen  again,  the  "new"  installation  instructions  for  MFT  were 
written  down  and  filed  with  the  MFT  disc.  These  installation 
instructions  are  provided  below.  A  five-minute  installation  job 
took  over  three  weeks  to  accomplish. 

The  instructions  are  as  follows: 

1.  Install  MFT 

2 .  Restart  coir^uter 

3.  Go  to  Start  Menu  in  bottom  left  corner  of  screen 

4.  Select  "Run" 

5.  Type  "Regedit" 

6.  Hit  "Enter"  key 

7 .  You  should  now  be  in  the  "Registry  Editor"  screen 
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8. 

9. 

10. 
11. 
12. 
13  . 

14. 

15. 

16. 


17. 

18. 


Select  "Hkey_LOCAL_MACHINE" 

Now,  click  on  "SOFTWARE"  folder 

Next,  click  on  "AGI"  folder 

Next,  click  on  "STK"  folder 

Then,  select  "LicenseData  "  folder 

Now,  select  "Edit"  from  the  top  toolbar 

Select  "New"  and  "String  Value" 

Rename  the  new  folder  as  "MFTv.O" 

Now,  right  click  the  mouse  button  and  enter  the 
following  data  in  the  "Value  data:"  box: 

"HostIDi: Password”  ***NOTE:  The  Host  ID#  is  the  host 
ID  number  of  the  computer  station  you  are  currently 
on.  Next,  type  a  colon  and  without  spacing  after  the 
colon,  type  the  respective  password  to  the  host  ID 
niimber.  The  respective  password  is  the  password  for 
the  computer  station  you  are  currently  on. 

Click  "OK" 

You  should  now  be  able  to  run  MFT  from  the  Start  Menu 


With  both  applications  open.  Satellite  Tool  Kit  and  Missile 
Flight  Tool  interface  with  each  other  through  the  STK  Connect 
module.  This  module  allows  a  simple  IPC  connection.  What  is 
not  so  simple  is  establishing  this  connection.  To  the 
established  user,  the  connection  is  made  with  two  clicks  of  the 
mouse.  For  the  non-established  user,  one  must  first  obtain  the 
password  and  password  expiration  date  from  Analytical  Graphics, 
Inc.  The  password  and  expiration  date  had  to  be  manually 
installed  for  this  module  as  well. 

Once  MFT  was  installed  and  the  STK/MFT  interface 
established,  the  launch  and  inpact  sites  were  inputted.  We 
chose  to  simulate  an  ICBM  launch  from  Paris,  France;  New  York 
City,  USA  was  chosen  to  be  the  primary  impact  site,  or  target, 
and  Washington  D.C.  was  chosen  as  our  decoy  inpact  site.  There 


10 


was  no  rhyme  or  reason  as  to  why  Paris  should  strike  New  York. 
Nor  was  there  any  reason  as  to  why  we  chose  Washington  D.C.  as 
our  decoy  impact  site. 

Given  the  launch  and  impact  sites,  we  determined  the  type 
of  missile  that  would  be  modeled.  An  LGM-30  Minuteman  III 
intercontinental  ballistic  missile  was  selected  as  our  threat 
ICBM  because  it  closely  resembled  an  MFT  missile  option. 
Specifically,  the  MFT  LRM_2-12000  missile  model  was  selected. 
This  missile  "...is  a  strategic  ICBM- type  missile  with  a  12000  km 
maximum  range,  three  stages  and  a  PBV  [Post  Boost  Vehicle]  with 
three  RVs."^  The  actual  Minuteman  III  missile  has  a  range  of 
10000-plus  kilometers,  three  stages  and  is  capable  of  carrying 
three  warheads . ^ 

Our  simulation  called  for  us  to  model  only  two  RVs,  one 
primary,  one  decoy.  Since  the  LRM_2-12000  missile  carried  three 
RVs,  we  had  to  modify  the  ICBM  model  in  MFT.  This  was 
accomplished  by  targeting  two  of  the  warheads  to  impact  New  York 

f iigufe  A*  of F9V  maniG-jJvcffi;. 


Figure  1.  Sample  Post-Boost  Vehicle  sequence 
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city  (one  became  redundant) ,  while  the  third  satisfied  the  decoy 
requirement  in  our  simulation.  MFT  is  able  to  model  four  types 
of  Post-Boost  Vehicle  configurations,  meaning,  there  are  four 
different  ways  the  reentry  vehicles  can  be  deployed.  Figure  1 
(reprinted  from  Appendix  A  of  the  MFT  user's  manual)  illustrates 
a  possible  Post-Boost  Vehicle  sequence.  To  ensure  the  viewer 
attains  an  accurate  representation  of  the  RVs'  deployment  and 
descent,  I  instructed  STK  to  display  only  the  decoy  and  one  of 
the  primary  RVs . 

The  initial  threat  selection  was  the  LGM-118A  Peacekeeper 
ICBM  which  can  deliver  up  to  10  RVs  with  greater  accuracy  than 
any  other  ballistic  missile.  It,  too,  has  three  stages,  and 
like  the  Minuteman  III,  has  a  range  of  10000-plus  kilometers. 
With  the  end  of  the  Cold  War,  however,  the  United  States  agreed 
to  eliminate  the  Peacekeeper  missiles  and  institute  the 
Minuteman  as  the  only  land-based  ICBM  in  the  nuclear  Triad.  The 
desire  to  keep  the  simulation  as  true-to-life  as  possible 
resulted  in  rejection  of  the  Peacekeeper.^ 

The  final  'initial'  decision  our  GBI  team  had  to  make  was 
the  simulation  time  step  for  propagation  of  the  threat.  We 
determined  that  the  EICV  needed  a  relatively  small  time  step  to 
accurately  achieve  a  close-encounter  approach  with  the  enemy 
ICBM.  Therefore,  we  selected  a  time  step  of  0.1  seconds. 
Unfortunately,  Missile  Flight  Tool  would  not  model  the  ICBM's 
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flight  in  such  a  small  time  step.  In  light  of  this,  our  time 
step  became  the  time  step  that  MFT  was  able  to  propagate, 
namely,  one  second. 

The  above  decisions  enabled  the  propagation  of  the  ICBM  and 
attainment  of  the  truth  data  needed  for  the  rest  of  the 
simulation.  MFT  is  very  sensitive.  One  must  follow  a  certain 
process  of  inputting  data  before  MFT  will  fully  compute  the 
trajectory  of  the  ICBM.  Also,  there  were  many  nuances  of  the 
Satellite  Tool  Kit  operating  system  during  the  link-up  between 
STK  and  MFT;  some  of  these  nuances  are  detailed  later  in  this 
paper.  After  many  hours  of  frustration,  the  solution  to  the 
STK/MFT  operating  dilemma  was  obtained  by  writing  down,  step-by- 
step,  the  correct  way  to  work  with  MFT  and  STK.  With  a  click  of 
a  few  buttons,  truth  data  was  obtained  and  exported  it  to 
Satellite  Tool  Kit.  Figure  2  displays  the  end  result  of 
propagating  a  missile  and  visualizing  it  using  STK. 


Figure  2.  Reentry  vehicles  descending  to  their  targets. 

RV_3  is  the  decoy  reentry  vehicle  on  its  way  to  Washington 
D.C.,  while  RV_1  is  the  primary  target  RV.  One  can  see  in 
Figure  2  that  the  third  stage  descends  after  it  has  deployed  the 
RVs . 

Interfaces 

The  MATLAB  Simulink  and  Stateflow  programs  and  the  ICBM 
truth  file  was  used  to  arrive  at  each  component's  output. 
Unfortunately,  STK  and  MATLAB  did  not  directly  interface  with 
each  other.  Therefore,  before  Simulink  could  read  the  truth 
data,  it  was  transformed  into  a  MATLAB  m-file.  This  was  a 
simple  process  of  first  saving  the  truth  data  as  a  text  file, 
then,  modifying  that  text  file  as  MATLAB  code. 
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Outputs  from  Simulink/Stateflow 

To  output  the  data  generated  by  the  different  simulation 
components  in  Siimlink  and  Stateflow  to  STK,  each  data  file  was 
saved  as  a  text  file .  Each  file  had  to  be  in  a  particular  STK 
readable  format,  though.  For  example,  the  GPS  satellites  in  our 
simulation  were  not  created  in  STK.  Instead,  their  locations 
and  orbits  were  defined  in  MATLAB.  To  display  their  locations 
at  each  time  step  in  STK,  each  GPS  satellite's  ephemeris  must  be 
imported  to  the  STK  application;  importing  data  is  done  by 
creating  a  text  file  with  the  necessary  information  in  the 
necessary  location.  In  our  case,  the  satellites'  latitude, 
longitude,  altitude,  latitude  rate,  longitude  rate  and  altitude 
rate  is  needed  at  each  time  step.  The  exact  format  for  an 
ephemeris  file  (.e)  can  be  found  on  pages  C-9  to  C-17  in  the  STK 
User's  Manual.^ 

Further,  to  model  the  infrared  satellites  (IR  sats) 
correctly,  the  azimuth  and  elevation  at  each  time  step  of  the 
onboard  sensor's  cone  angle  must  be  imported  into  an  STK  sensor. 
The  azimuth  and  elevation  will  be  generated  in  Simulink  and 
saved  in  an  STK  readable  format,  namely,  a  text  file. 

The  following  items  will  be  imported  into  STK  once  the 
Simulink  output  files  are  generated:  the  EKV  and  its  flight 
path,  the  pointing  angles  of  the  IR  sensors  and  search  and  track 


radars  and  the  GPS  satellites.  The  EKV  data  file  that  will  be 


imported  into  STK  will  be  formatted  similar  to  the  ICBM  truth 
file.  The  EKV  data  file  will  contain  the  kill  vehicle's 
latitude,  longitude,  altitude,  latitude  rate,  longitude  rate  and 
altitude  rate  at  each  time  step.  By  importing  the  pointing 
angles  of  the  IR  sensors  and  the  search  and  track  radars,  we 
will  able  to  accurately  display  when  a  sensor  or  radar  is  able 
to  see  the  ICBM.  Knowing  when  the  sensors  and  radars  have 
access  to  the  ICBM  aids  in  the  ease  of  understanding  our  GBI 
simulation. 

We  had  to  decide  on  locales  for  each  of  the  sites  -  the 
radar  site,  the  locations  for  the  IR  sats  and  the  EKV  site  - 
before  we  could  begin  to  think  about  importing  any  data  into 
STK.  Our  decisions  were  based  on  a  combination  of  technical  and 
non-technical  reasons.  Access  times  with  the  ICBM  drove  the 
location  of  the  radar  site;  resolution,  pointing  angles  and 
access  times  drove  the  placement  of  the  IR  sats  and  kill  time 
drove  the  location  of  the  EKV. 

Modeling  of  radars 

The  radars  were  located  at  Daqortoq,  Greenland  as  phased- 
array  radars.  Unfortunately,  STK  does  not  have  the  option  to 
model  a  phased-array  radar.  To  compensate,  the  radars  were 
modeled  as  sensors  until  such  a  time  when  actual  radar  data  from 
Simulink  is  available  for  import.  The  sensor  options  available 
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1.  Coitplex  Conic 

2 .  Rectangular 

3 .  Half -Power 

4 .  Synthetic  Aperture  Radar 

5 .  Sin5)le  Conic 

The  search  and  track  radars  were  modeled  as  simple  conic  sensors 
since  this  was  the  easiest  option  to  understand  and  work  with. 

Before  modeling  the  radars  in  this  fashion,  we  ensured  that 
the  viewer  would  still  able  to  able  see  and  understand, 
visually,  how  the  search  and  track  radars  play  their  part  in  our 
simulation.  We  defined  the  parameters  for  the  two  sensors,  one 
search  and  one  track. 

I 

Figure  3,  below,  is  a  two-dimensional  depiction  of  the 
search  and  track  radars  seeing  the  ICBM  and  tracking  it  along 
its  trajectory. 


Jjjo _ jio _ 60  _ AU  « 


Figure  3,  Radars  have  access  to  ICBM  and  actively  track  it. 

The  orange  parabaloid  around  the  missile  shows  that  the 
search  radar  can  see  the  ICBM.  The  white  box  around  both  the 
Daqortoq  site  and  the  missile  shows  that  the  track  radar  has 
access  to  the  ICBM.  The  white  line  in  between  the  two  tells  the 
viewer  that  the  Daqortoq  site  is  actively  tracking  the  ICBM.  As 
a  point  of  interest,  one  can  see  in  Figure  3  as  well,  the  second 
stage  and  the  shroud  of  the  enemy  ICBM  have  already  separated 
from  the  missile. 

Figure  4,  below,  is  a  three-dimensional  version  of  the 
scene  depicted  above.  In  this  figure,  however,  the  viewer  can 


1 


readily  see,  not  only  the  trajectory  of  the  ICBM,  but  the  orange 
cone  angle  of  20  degrees  that  represents  the  search  radar  and 
the  1  degree  cone  angle  that  represents  the  track  radar. 


Figure  4.  The  search  radar  (orange)  and  track  radar  (white)  track  the  enemy  ICBM. 


Again,  as  a  point  of  interest,  one  can  readily  see  the 
trajectory  of  the  different  stages  of  the  ICBM.  The  white  line 
spanning  the  Atlantic  Ocean  is  the  ICBM's  ground  track. 

Modeling  of  IR  sats  and  sensors 

The  infrared  sensors  designed  to  detect  the  laiinch  of  the 
enemy  ICBM  were  placed  onboard  geostationary  satellites .  From 
this  altitude,  the  IR  sensors  could  trace  the  entire  surface  of 
Earth.  STK's  different  sensor  options  allow  modeling  the 
spiraling  action  of  the  actual  IR  sensor  until  actual  azimuth 
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and  elevation  pointing  angles  of  the  sensor  from  an  Simulink 
output  file  is  available.  With  the  options  given  me  by  STK,  we 
modeled  the  spinning  movement  of  the  IR  sensor  about  its 
boresight  by  defining  a  spin  rate  and  a  single  set  of  pointing 
angles . 

Working  together,  the  two  sensors  see  the  ICBM  throughout 
its  flight.  One  of  the  downfalls  of  STK,  however,  was  that  once 
the  sensors'  spin  rates  and  pointing  angles  were  defined,  the 
actual  'workings'  of  the  sensors  could  not  be  modeled.  To 
explain,  once  the  initial  spin  parameters  for  the  IR  satellites' 
sensors  were  defined,  the  transition  from  searching  to  tracking 
the  missile  with  the  IR  sensors  (that  is,  IR  sensors  attaining  a 
'lock'  on  the  target)  could  not  be  modeled.  This  problem  will 
be  relieved  when  the  IR  pointing  angles  from  the  Simulink  output 
file  are  available.  This  data  will  allow  modeling  of  the  proper 
spiral  spin  of  the  sensor  and  model  its  transition  from  a  search 
mode  to  a  tracking  mode. 

This  is  not  to  say  that  the  IR  sensors  attaining  a  lock  on 
the  target  cannot  be  modeled  without  the  Simulink  data.  Adding 
two  more  satellites,  each  with  its  own  sensor,  to  the  scenario 
will  relieve  this  problem.  These  additional  sensors  could  be 
defined  with  the  proper  parameters  so  that  they  "turn  on"  once 
they  see  the  ICBM.  Keeping  in  mind  our  goal  of  simulating  a 
real  world  event,  this  technique  was  rejected. 
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Modeling  o£  EKV 

The  Exoatmospheic  kill  vehicle  will  be  launched  from  New 
York  City  once  it  is  determined  that  it  can  see  the  incoming 
ICBM.  To  watch  this  critical  event  happen  in  our  simulation,  a 
sensor  was  placed  on  the  kill  vehicle.  As  the  EKV  headed  on  a 
collision  course  with  the  ICBM,  the  sensor's  continued  lock  on 
the  target  was  visualized  in  STK  much  like  the  track  radar 
displayed  it  had  a  lock  on  the  ICBM.  A  white  line  connected  the 
two  objects,  and  a  while  square  was  seen  around  the  locked-on 
vehicle . 

An  approximate  model  of  the  EKV  launching  was  not  possible 
without  the  outputted  Simulink  data  as  done  with  the  IR  sats  and 
the  radars.  Neither  STK' s  ballistic  propagator,  nor  MFT' s 
ballistic  propagator  was  precise  enough  to  model  an  intercept 
missile.  Therefore,  a  visual  how  the  EKV  attacks  the  ICBM  can 
not  be  generated  until  the  EKV  trajectory  data  is  output  from 
Simulink  in  a  text  file. 

Modeling  of  GPS  sats  and  battle  manager 

The  GPS  satellite  model  was  the  simplest  model,  aside  from 
the  battle  manager,  to  integrate  within  STK.  All  that  was 
required  to  model  the  GPS  satellites  was  each  satellite's 
position  and  velocity  at  each  time  step.  This  information  was 
supplied  from  a  MATLAB  module  in  a  text  file.  Since  the  GPS 
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satellites  only  pass  information  to  the  EKV,  only  the  satellites 
themselves  need  to  be  visualized. 

Originally,  two  EKVs  and  their  positions  were  going  to  be 
visualized;  one  based  the  Simulink  output  and  the  other  based  on 
the  GPS  truth  data,  that  is,  where  the  GPS  satellites  thought 
the  EKV  was.  However,  since  the  GPS  model  was  so  accurate,  it 
was  unnecessary  to  display  both  trajectories. 

Like  the  GPS  satellite  model,  the  battle  manager  model  did 
not  require  any  elaborate  displays  in  STK.  Therefore,  a 
facility  was  placed  in  Colorado  Springs,  USA  that  represented 
the  battle  manager's  location. 

Analysis  and  conclusions 

Troubles  encountered  during  mission 

Once  MFT  was  installed  properly,  and  once  all  the  nuances 
of  the  STK/MFT  interface  were  understood,  the  addition  of  models 
was  fairly  easy.  Further,  once  all  the  pieces  to  our  simulation 
puzzle  were  put  together,  STK' s  promise  of  making  analysis  of 
complex  scenarios  came  true.  Below  is  a  quick  summary  of  the 
major  problems  encountered.  Had  it  not  been  for  these  problems, 
more  time  would  be  available  to  add  fidelity  to  visualization 
portion  of  our  GBI  simulation. 
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1.  The  Missile  Flight  Tool  module  is  not  provided  on  the 
standard  Satellite  Tool  Kit  CD;  MFT  requires  its  own 
separate  CD . 

2.  To  access  any  STK  module,  such  as  Missile  Flight  Tool, 
one  must  have  a  password  and  either  an  expiration  date  or  a 
Host  ID  number  for  his/her  computer  station. 

2.  Most  likely,  one  will  have  to  manually  install  the 
password  and  Host  ID  number /expiration  date.  This  requires 
the  user  to  be  either  extremely  familiar  with  his/her 
computer  or  extremely  friendly  with  the  Analytical 
Graphic's  technical  support  staff! 

4.  Any  changes  a  user  wishes  to  make  to  his/her  MFT 
scenario  after  he/she  has  exported  the  scenario  to  STK 
requires  that  the  user  begin  the  simulation  completely 
anew . 


Growth  possibilities 

Given  more  time  to  work  on  this  simulation,  there  a  number 
of  other  scenarios  we  could  model  and  simulate.  For  example,  it 
is  possible  to  model  the  random  affects  of  wind  magnitudes  and 
directions  on  the  ICBM  and  EKV  as  they  travel  along  their 
trajectories.  Moreover,  it  is  possible  to  include  several 
different  launch  sites  into  our  simulation.  Obviously,  though, 
this  would  require  the  addition  of  more  search  and  track  radars 
and  more  IR  satellites. 
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